304558 - Bookmark All Tabs: A bad name is better than no name

Status: RESOLVED INACTIVE

(Firefox :: Bookmarks & History, enhancement)

Description

[James Slaughter]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050812 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050812 Firefox/1.0+

A recent change means that when bookmarking a set of tabs, the folder name is
"[Folder Name]" rather than the caption of the active tab. This creates a
problem when multiple sets of tabs are saved temporarily.

A common use-case for the Bookmark All Tabs feature is to quickly preserve a set
of pages that will be revisited when time allows, after which the bookmarks will
be discarded. The folder name is not important in such cases, providing it can
disambiguate between other saved 'sessions', but that property has been lost.


Reproducible: Always

Steps to Reproduce:
1. Save a set of tabs, perhaps from Peter(6)'s Firefox build notes
2. Repeat with a set of tabs from a different window that you happen to have open
3. Pretend that you've upgraded Firefox and wish to resume browsing

Actual Results:  
To determine which set of tabs is which, I must either name them differently in
steps 1 and 2, or look at the names in the folder. Both methods slow me down and
make the browsing experience more cumbersome.


Expected Results:  
By choosing a 'reasonable' name as before, the sessions can be differentiated
more easily. There's no magic answer for the folder name, but the best is the
enemy of the good.


The keyboard access to bookmark all tabs is also more difficult. There's no
(obvious) accelerator on the menu, nor shortcut key to open the dialogue. While
the changes make the Bookmark All Tabs feature more prominent, I feel it was
already readily discoverable when adding bookmarks and the visibility doesn't
justify these impediments.

I have raised this as a bug rather than an enhancement, because I feel it is a
significant usability regression. Please amend if necessary.

Comment 1

[Peter van der Woude [:Peter6]]

No data is lost and it's just a name.

So this is very much an enhencement/request for improvement.

Comment 2

[Martijn Wargers (dead)]

I suspect this was changed here with the patch for bug 300412:
   var dialogArgs = currentTabInfo;
+  if (aBookmarkAllTabs) {
+    dialogArgs = { name: gNavigatorBundle.getString("bookmarkAllTabsDefault") };
+    dialogArgs.bBookmarkAllTabs = true;
+  }
See also the comments in that bug.

So it was done on (semi-)purpose, and that would mean this bug could become a
WONTFIX.

Comment 3

[James Slaughter]

(In reply to comment #2)
> See also the comments in that bug.

I didn't see any that were relevant. Was there some discussion as to why the
change to the default folder name was made? It seems "obvious" that there's no
single correct name for the folder, and therefore natural that this is a
consequence, until you consider the usability issues it introduces. For me, not
having a shortcut key to bookmark all tabs and being forced to choose a name is
something of a nuisence.

> So it was done on (semi-)purpose, and that would mean this bug could become a
> WONTFIX.

As long as someone understands the issue and considers it before doing that,
I'll be content.

Comment 4

[Martijn Wargers (dead)]

Well, it wasn't specifically commented in bug 300421, but I was more or less
coming to the conclusion in comment 2, because of the lack of protest from the
reviewers in the patch for bug 300421.
cc-ing the patch-maker of bug 300412, [e-mail] (I hope you don't mind).

Comment 5

[Martijn Wargers (dead)]

Er, comment 4: where I said bug 300421, I meant bug 300412.

Comment 6

[gsshih]

The reason why the default name was changed was from usability studies showing
that users were confused about the name being one of the bookmarks.  Perhaps if
the label value of the textbox showed "Folder Name: " instead of "Name: " while
keeping the original default would be better?

-grace

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

Changing the textbox label would definitely help:
   .---------------------------------------------------,
   | Add Bookmarks for All Tabs                        |
   |---------------------------------------------------'
   | Folder Name: [ Tabs from 2005-08-01       ]       |
   | Create In  : [ Bookmarks                |v]  [v]  |
   |                                                   |
   |                                  [ OK ] [ Cancel] |
   '---------------------------------------------------'

If we can come up with some relatively reasonable heuristic to use as a default
name for the folder, I'd rather see that than something that *must* be replaced.
Also, when the auto-filled content is constant (instead of based on selection)
we run the risk of presenting a default value that could easily create duplicate
entries :(

Maybe something based on the current date and time (shown in example above)? Or
"%firstTabName - %secondTabName"? Grasping at straws a little here ...

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

Looking at this from a step back, I'm becoming more convinced that the problem
is a mismatch between the action name ("Bookmark all Tabs") and the end result
(a folder of bookmarks is created). Nowhere do we tell the user that the thing
they create is a folder of bookmarks.

In my above ASCII art, I changed the title of the dialog from "Bookmark All
Tabs" to "Add Bookmarks for All Tabs". Not that I seriously believe that anyone
reads those things, but perhaps "Add Folder for Bookmarks from Tabs" would be
better? 

Comment 9

[Hideo Oshima]

Can't reproduce with places-enabled build.
Worksforme?

Comment 10

[Phil Ringnalda (:philor)]

Certainly not WFM: the reporter's original concern was that telling two folders quickly saved, both named "[Folder Name]" made it difficult to tell them apart. Now his two quickly saved folders will both be named "". If the Places version is using a blank default for very carefully tested reasons that overrule the reporter, and the original implementer, and MoCo's UI lead, then WONTFIX would be the appropriate resolution.

Comment 12

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.